昨天，我們一覽了澎湖的美景，並科普了 DevOps 的定義；剛好今天是 Red Bull 首次在台中港舉辦飛行日，我也特別到現場同歡，就應景的以這個荒誕又有趣活動當引子，向大家介紹敏捷開發與實踐的方法。

所以我說那個敏捷呢 ?

我們來假設一下兩種情境，先讓我們乘坐時光機回到幾個月前，某個知名 Youtuber 團隊老闆，決心要參加這次的 Red Bull Flugtag。

情境 A

老闆一邊喊著我很忙我等等還要做直播，一邊發起了會議通知，並且在他的筆記本上寫下他的時程計畫:

1. 開會前先蒐集資料，可能包含飛行動力學，飛機的結構與材質，外觀設計的提案 - Owner XXX
2. 設計結構，外型，還有開賽前的表演 - Owner OOO
3. 實作飛機，包含建主幹、打釘子、塞泡棉糊紙板等 - Owner YYY
4. 測試飛行與行前排練 - Owner ZZZ
備註: 預留約一周時間做調整

在完成會議後，旗下的成員便根據結論繪製外型，設計結構，並把設計圖交給負責實作的 Owner 團隊，把飛機的骨架建起來、組裝機翼以及上色。

終於在開賽的前一周，老闆看向面前的飛機，皺起了眉頭說了句: 這不是我要的，並指出了幾個點。

• 比例放大後，飛機上寫的字反而看不清楚。
• 還沒飛出去翅膀就看起來搖搖欲墜，用木材當主幹落水前絕對會斷掉
• 機身的比重不太對，有翻機風險

問了問團隊，他們無辜的說，我們也是照著設計圖跟指示去做的。這時比賽還有預留一周的時間，老闆親自坐鎮，開始嘗試用最快的方式改善這些問題...

情境 B

老闆心想，烙賽這麼多次，總是因為計畫敢不上變化，來想個辦法讓問題可以提早做改善。

首先，老闆一樣規劃出完成飛機必要的元素，但是:
1. 以 "華麗的落水" 為目標，但先不將每個細節寫死
2. 在每個項目建構的過程都讓成員參與並溝通
3. 每個階段都安排相關的測試，如比重、遠近外觀等
4. 遇到問題則立即處理及調整，或是規劃成代辦事項

最後，兩個不同時空的老闆都華麗落水了。

關於敏捷開發

先看看情境

參考上述的兩個假設，不難看出情境 A 下的老闆制定了嚴謹並清楚的工作程序，並將責任歸屬於特定的組員們；然而這也導致在製作的過程中，遇到了問題非常難以修改，且當老闆在最後驗收時發覺哪裡不對勁，想要調整的成本十分巨大。

在傳統的瀑布式開發下，整個開發的過程會有完整的計劃，UI/UX 會繪製 wireframe，SA 會開立規格並由 PG 實踐規格，好處是當需求非常固定時，責任的分工可以高效的執行，完善的設計架構甚至能夠讓剛入行的 PG 們成為即戰力，只要有寫得非常清楚的規格書。

但相對的，在各職位之間就需要大量的文件做媒介，在製作與解析上都需要消耗時間、同時也只有在全數完成時才能交付成果，常無法確切適應顧客的需求。

什麼是敏捷開發

敏捷開發，是描述軟體以反復迭代的方式進行開發，目的是快速的應對需求的變化。

同時，敏捷開發又強調開發團隊與客戶之間的溝通，並藉由頻繁的交付增量 (increment，可以由顧客定義，通常是能夠運行的軟體版本)，不斷進行改進，來因應需求變化。

在敏捷開發的過程中，常會先規劃大概的方向，並逐步讓規格的顆粒度由粗轉細；經 UXR 研究與 SA 訪談後，先建立顆粒度較粗的規格交由 SD/PG 試做，並交付予客戶接收回饋，經確認後再逐步迭代這些步驟，並由試做逐漸擴大為實作，讓最終的產出與客戶預期的誤差降至最低。

另外，敏捷的精神亦強調成員須備有積極的態度，以及由經驗中學習並反應的能力。

今日總結

今天，我們用皂飛機的案例簡單解釋了敏捷開發的精神，明天，我們在介紹敏捷開發的實作方法後，就正式的規劃 ColorCodeTag 專案。

迷之聲: 如果客戶需求一直改怎麼辦 ?

參考連結

Azure What is agile